After resizing the main partition, we have the following logic to invoke
`partprobe` if it is on a loop device:

    # Loop devices need a prod
    if [ -n "$using_loop" ]; then
      partprobe $root_disk
      udevadm settle
    fi

But empirically this block does not run on a fresh dual-boot
installation: the kernel still believed the partition has its old size
until I manually ran partprobe. As a result eos-firstboot fails to grow
the main partition:

    eos-firstboot[528]: resize2fs 1.47.0 (5-Feb-2023)
    eos-firstboot[528]: The filesystem is already 11053568 (4k) blocks long.  Nothing to do!

$using_loop is conditionally set as follows:

    case ${orig_root_part} in
      /dev/loop?p?)
        using_loop=1
        ;;
    esac

$orig_root_part is set as follows:

      orig_root_part=$(systemctl show -p What sysroot.mount)
      orig_root_part=${orig_root_part#What=}

I ran this command once the system had booted and the output is:

    What=/dev/disk/endless-image3

This is not too surprising because eos-image-boot-generator has the
following:

    cat <<EOF >${GENERATOR_DIR}/sysroot.mount
    [Unit]
    Before=initrd-root-fs.target
    Requires=systemd-fsck-root.service
    After=systemd-fsck-root.service
    [Mount]
    What=/dev/disk/endless-image3
    Where=/sysroot
    Options=$rwflag
    EOF

So the fix is to follow any symbolic links so we can inspect the real
device path. Conveniently we already do this:

    # Identify root partition device node and parent disk
    root_part=$(readlink -f "${orig_root_part}")

https://phabricator.endlessm.com/T35432